refactor(l1): discovery service - #1768
Conversation
…o its own folder and files
allow many arguments is a temprarily fix, this will be soled in #1768
f34f403 to
e3e68a4
Compare
|
| let digest = Keccak256::digest(msg.get(65..).ok_or(RLPxError::InvalidMessageLength())?); | ||
| let signature = &Signature::from_bytes( | ||
| msg.get(..64) | ||
| .ok_or(RLPxError::InvalidMessageLength())? | ||
| .into(), | ||
| )?; | ||
| let rid = RecoveryId::from_byte(*msg.get(64).ok_or(RLPxError::InvalidMessageLength())?) | ||
| .ok_or(RLPxError::InvalidRecoveryId())?; | ||
| let peer_pk = VerifyingKey::recover_from_prehash(&digest, signature, rid)?; |
There was a problem hiding this comment.
I remove this because it is recovering the pubkey points bytes (node_id) from the msg, something we already do when decoding the packet (see https://github.com/lambdaclass/ethrex/blob/main/crates/networking/p2p/discv4.rs#L87-L97).
There was a problem hiding this comment.
This is great, missed to comment this on previous review!
| pub(crate) type RLPxConnBroadcastSender = broadcast::Sender<(tokio::task::Id, Arc<Message>)>; | ||
|
|
||
| // https://github.com/ethereum/go-ethereum/blob/master/p2p/peer.go#L44 | ||
| pub const P2P_MAX_MESSAGE_SIZE: usize = 2048; |
There was a problem hiding this comment.
The spec doesn't mention a max size but we were using the max size of the discovery protocol, and reading geth code they define 2048 as the max packet size in rlpx, see here.
| tracker.spawn(networking); | ||
| .await.expect("Network starts"); |
There was a problem hiding this comment.
Note that we don't need to spawn the networking as a task. This allows us to panic if there is an err during the network startup.
ElFantasma
left a comment
There was a problem hiding this comment.
Most comments are minor issues. And some may be wrong 😬
Good work overall!
**Motivation** Discovery service was becoming too big and unmanageable to be inside `net.rs`. **Description** This refactor splits the discovery service into its own structs and files, now the flow is: - `Discv4` struct: handles the core logic of the `discv4` protocol - Loading bootnodes - Listening for incoming connections and handling messages - Managing revalidations - Initiating lookups - `Discv4LookupHandler`: the complexity of the lookups is encapsulated in this struct. The following improvements have also been made: - All Tokio tasks are now spawned using the tracker. - When receiving neighbors' messages, now we check we do not add ourselves to the table (which could occur occasionally). - Error handling has been improved, and the verification logic is now more readable, especially within message handling. Closes None
Motivation
Discovery service was becoming too big and unmanageable to be inside
net.rs.Description
This refactor splits the discovery service into its own structs and files, now the flow is:
Discv4struct: handles the core logic of thediscv4protocolDiscv4LookupHandler: the complexity of the lookups is encapsulated in this struct.The following improvements have also been made:
Closes None